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DISPOSITIF ET PROCEDE DE CHARGEMENT DE COMMANDES 
DANS UNE CARTE A CIRCUIT INTEiGRE 

La presente invention conceme un dispositif de chargement de 
commandes a partir d'au moins un serveur vers au moins une carte a 
circuit integre connectee a une unite d'abonne, ladite carte comprenant 
un premier programme d'execution de commandes et une premiere 

5 memoire. EUe conceme egalement un procede de chargement de 
commandes d'un tel dispositif. 

Un tel dispositif s'applique en particulier pour les cartes 
comprenant des services tels que des services concemant le domaine de 
la sante. de la telephonic mobile, ou encore, des services relatifs au 

10 domaine bancaire. 

En vue de permettre a un utilisateur de la carte d'acceder a un 
service, Tetat de la technique propose des dispositifs qui prevoient de 
charger dans la premiere memoire de la carte, un ensemble de 
commandes audit service, et de pouvoir effacer ou remplacer la totalite 

15 du service par un autre service dans le cas ou il ne serait plus utilise, et 
ce au moyen du serveur. Lorsque Tutilisateur accede au service, le 
premier programme d'execution execute le service ainsi resident dans la 
carte. 

Bien que ces dispositifs permettent de charger la totalite des 
20 commandes propres a un service, toutes les commandes sont 
sauvegardees dans la premiere memoire de la carte comprenant 
generalement plusieurs services residents, ce qui peut etre genant du 
fait de la taille limitee de la memoire des cartes a circuit integre. De 
plus, le temps de chargement d'un service est sensiblement important. 
25 Enfin, dans le cas ou seules quelques donnees du service ont change, 
afin de valider lesdits changements, il est necessaire de recharger tout 
le service, ce qui pose un probleme d'efficacite en terme de temps. 
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Aussi un probleme technique a resoudre par I'objet de la presente 
invention est de proposer un dispositif de chargement de commandes a 
partir d au moins un serveur vers au moins une carte a circuit integre 
connectee a une unite d'abonne, ladite carte comprenant un premier 
5 programme d'execution de commandes et une premiere memoire, ainsi 
qu'un precede de chargement d^un tel dispositif. qui permettraient 
d«une part, d'eviter des pertes d'espace memoire dues aux sauvegardes 
en memoire de tous les services utilises, et, d'autre part, de diminuer le 
temps de chargement d'un service. 

10 Une solution au probleme technique pose se caracterise. selon un 

>remier obiet de la presf^nt^ 
serveur comprend : 

- des moyens de chargement dans la carte d'au moins un bloc 
d'une sequence de commandes, propre a un service, au moins 

15 une commande dudit bloc etant executee par le premier 

programme d'execution ou transmise a Tunite d'abonne et 
executee par un deuxieme programme d'execution. 

- des moyens de sauvegarde d'au moins un bloc de sequence 
dans la premiere memoire, 

20 - des moyens de mise a jour etant aptes a modifier, effacer. 

ajouter. dans la premiere memoire au moins un bloc de 
sequence, 

et, d'autre part, la carte comprend : 

des moyens de recherche de bloc de sequence etant aptes a 
25 rechercher un bloc de sequence propre a un service, apr^s I'execution 
d'une commande d\in bloc. 

Scion un second objct dc la prcscntc invention, cettc solution se 
caracterise c„ cc que le precede dc chargement comporte les 6tapcs 
selon lesquelles : 
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- on charge, a partir du serveur vers la carte, au moins un bloc 
de sequence de commandes, propre a un sendee, 

- on execute au moins une commande dudit bloc au moyen du 
premier programme d'execution ou on la transmet a Vunite 
d'abonne et on Texecute au moyen d'lm deuxieme programme 
d'execution. 

- on sauvegarde au moins un bloc de sequence dans la premiere 
memoire). 

Ainsi, comme on le verra en detail plus loin, le dispositif de 
^ 10 rinvention permet, d'une part, d'avoir une augmentation de la taille 

mp^moire disponible de la carte en ne sauvegardant qu'une partie des 

commandes propres a un service, representees par un bloc de 
sequence, et, d^autre part, de gagner du temps lors d'un chargement, en 
ne chargeant que des blocs de sequence et en ne mettant a jour que les 
15 blocs ou donnees devant etre modifiees. 

La description qui va suivre au regard des dessins annexes, 
donnee a titre d'exemple non limitatif, fera bien comprendre en quoi 
consiste I'invention et comment elle peut etre realisee. 

La figure 1 est un schema montrant des serveurs et des cartes 
0^ 20 conformes a I'invention. 

La figure 2 est un schema d'vin serveur et d'une carte de la figure 

1. 

La figure 3 est un schema simplifie de services utilises par un 
utilisateur de la carte de la figure 2. 
25 La figure 4 est un schema d'une sequence de commandes 

associee a un service de la figure 3. 

La figure 5 est un schema d*une commande de sequence de la 
figure 4. 

La figure 6 est un autre schema d'une commande de sequence de 
30 la figure 4, 
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La figure 7 represente un premier echange d'informations entre la 
carte et le serveur de la figure 2. 

La figure 8 represente un second echange d'infoimations entre la 
carte et le serveur de la figure 2. 

La figure 9 est un schema plus detaiUe de la carte de la figure 2. 
La figure 10 represente un troisieme echange d'informations entre 
la carte et le serveur de la figure 2. 

La figure 11 est un schema de donnees d'une instruction 
echangee entre le serveur et la carte de la figure 2. 

La figure 12 est un autre schema montrant I'instruction de la 
figure 11. 



La figure 13 represente un quatrieme echange d'informations 
entre la carte et le serveur de la figure 2. 

Sur la figure 1 est represente un dispositif de chargement de 
15 commandes a partir d'un ou plusieurs serveurs SERV vers une ou 
plusieurs cartes CARD a circuit integre. Lesdites cartes sont connectees 
a des unites d'abonne SU. Comme le montre la figure 2. un serveur 
SERV comporte des moyens de chargement ML de sequences SEQ de 
commandes et des moyens de mise a jour MU de blocs sequences de 
20 commandes. Une carte CARD comporte une premiere memoire Ml. un 
premier programme d'execution PI de commandes et un bloc de 
contacts C destine a une connexion electrique avec une unite d'abonne 
SU. EUe comporte egalement des moyens d'interpretation MI de blocs de 
sequence de commandes. Une unite d'abonne SU comporte un ecran 
25 SCR et un deuxieme programme d'execution P2 de commandes. 

Un utiHsateur accede a un service S compris dans la carte CARD 
par exemple un service telephonique. au moyen de son unite d'abonne 
SU. La carte comporte couramment plusieurs services. Un service S fait 
appel generalement a un ou plusieurs autres services, comme le montre 
30 la figure 3. A un service est associe une ou plusieurs sequences SEQ de 
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commandes permettant I'utilisation dudit service par I'utilisateur. A. 
chaque service est associe tin identifiant S_ID. Une sequence SEQ de 
commandes comporte \m ou plusieurs blocs B comme le montre la 
figure 4. A chaque sequence est associe un identifiant de sequence 
5 SEQJD. 

Pour permettre Tacces a un service S par I'utilisateur, la carte 
CARD comporte des moyens de selection de service SERVICESELECT 
(non represente), lesdits moyens etant compris dans la premiere 
memoire Ml. Lorsque Tutilisateur allume son unite d'abonne, il a acces 
^ 10 a un menu affiche sur son ecran grace auxdits moyens de selection de 

e^mrir-^ f^RPVTCRSELECT. II selectionne un service. 

Selon un mode de realisation non limitatif, les etapes decrites ci- 
apres permettent de foumir le service choisi a I'utilisateur. 

Dans une premiere etape, on interprete dans la carte au moins un 
15 bloc de sequence de commandes grace aux moyens d' interpretation ML 
Dans notre cas, un premier bloc B de sequence de commandes propre 
au service selectionne est interprete et la preihiere commande CD a 
executer dudit bloc B est executee. On notera que la premiere 
commande a executer n'est pas forcement la premiere du bloc. Soit la 
9 20 commande CD est executee dans la carte par le premier programme 

d'execution PI, soit elle est transmise a I'unite d'abonne SU et executee 
par le deuxieme programme d'execution P2. 

Preferentiellement, Comme le montre la figure 5, une commande 
CD comporte les champs suivants : 
25 - une longueur CD_LEN, 

- un identifiant CD JD unique dans la sequence, 

- un type CDJTYPE de commande, 

- des parametres d'entree CD_PAR. 

Apres Texecution d'lme commande, comme le montre la figure 6 
30 on obtient les donnees suivantes : 
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- des donnees de resultat CD_RES, 

- des donnees de sortie CD_OUT donnant par exemple une 
valeur de code entree par Tutilisateur a la suite de I'execution 
d'une commande d'entree de code, 

5 - des donnees de liaison CD.LINK indiquant la commande 

suivante a executer. Ces donnees permettent de ne pas 
obligatoirement executer les commandes dans I'ordre de 
presence dans le bloc. 
Preferentiellement, les donnees de sortie CD.OUT ont un format 
10 de type TLV defini dans le standard GSM 11.14. 

Par exemple, on peut avoir une commande d'affichage He 



texte 



■ . . — .-»>^v> «-»V- 

DISPIAYTEXT sur Ificran de Tunite d abo™*. Ladite commande 
comprend comme parametre d'entrees : 

- un qualifiant DISPLAYTEXT_QUAL, 

" ^ identifiant destinataire DISPLAYTEXT_DDI, 

- des parametres DISPLAYTEXT_PAR propres a ladite 
commande. comme par exemple le texte a afficher. 

Preferentiellement, le type de commande DISPLAY_TYPE le 
qualifiant DISPLAY.QUAL et I'identifiant destinataire DISPLAY DDI 
20 sont ceux definis dans le standard GSM11.14 tandis que les parametres 
DISPLAY_PAR sont de format TLV. 

Preferentiellement, il existe des commandes permettant 
d'effectuer les actions suivantes : 

- executer un service, 

- sauvegarder une valeur de resultat de commande 
precedemment executee dans une variable, 

- terminer I'execution d'une sequence de commandes, 

- branchement vers une autre commande, 

- appel d'une autre sequence de commandes.... 
On notera que la liste des actions n'est pas exhaustive. 
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Par exemple, pour une commande de deioxieme type dont Taction 
est de mettre fin a Texecution d'un bloc de sequence et par suite d'une 
sequence, on axora les parametres suivants : 

- CD.LEN = 10, 
5 - CDJD = 2, 

. CD_TYPE = EXIT, 

- CD^PAR = 1, les donnees de sortie CD„OUT doivent etre 
envoyees au serveur SERV. 

Selon des valeurs des donnees de resultat CD_RES, 
10 preferentiellement, on execute Tune des actions suivantes : 

- on utilise les donnees de liaison CD_LINK afin de choisir la 

commande suivante a executer, 
. on execute la commande precedent la commande courante, 

- on affiche un texte a Tecran de Tunite d'abonne et on execute 
15 la commande precedent la commande courante, 

on ferme le service, 

- on affiche un message d'erreur a Tecran de l*unite d'abonne, et 
on termine le service, un message de terminaison est envoye 
au serveur SERV. 

20 Dans une deuxieme etape, apres que la premiere commande CD a 

executer de bloc B de sequence a ete executee, on recherche la 
commande suivante a executer, d'une part, dans le bloc B de sequence 
meme, d'autre pairt, dans la premiere memoire Ml de la carte si ladite 
commande ne se trouve pas dans le bloc de sequence, et, enfin, comme 

25 le montre la figure 7, au moyen d'une requete de bloc RB envoyee a 
partir de la carte vers le serveur, si la commande CD ne se trouve ni 
dans le bloc B de sequence, ni dans la premiere memoire Ml. Cela 
revient a rechercher un autre bloc de sequence, propre a un service, 
apres I'execution d'une commande d'lm bloc de sequence. Ainsi, soit le 
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bloc de sequence rechercM est envoye par le senreur SERV, soit le bloc 
de sequence recherche est issu de la premiere memoire Ml. 

Preferentiellement, la recherche dans le bloc B se fait au moyen 
de son identifiant unique CDJD tandis que la .^.her^he dans la 
premiere mimoire Ml se fait au moyen de son identifiant unique 
CDJD, de lidentiiiant de la sequence SEQJD en cours et du service 

Selon un mode de realisation particulier. une requete de bloc RB 
comprend les elements suivants : 

- I'identifiant du service S_ID en cours, 
ridentifiant de la se quence SRQ in 



- un identifiant de r«quete RB_ID, 

- un identifiant de la conunande CDJD a executer, 

- des donnees generales RB.DATA correspondant aux 
commandes CD executees precedemxnent a partir de la 
demiere requete quelconque falte au serveur. 

Chaque donnee generale RB.DATA comprend les elements 
suivants : 

- une longueur des donnees suivantes CD.LENDATA, 

- I'identifiant de la commands CDJD qui a ete executee, 

- des donnees resultats CD_RES, 

- des donnees de sortie CD_OUT. 

IWferentiellement. la demiere donnee est de fom«t TLV 
notamment defini dans le standard GSM 1 1.14. 

Ainsi, les donnees comprises dans la :^qu«e de bloc RB 
ournissent au serveur SERV un mqyen de tr«.age des actions de 
1 utiUsateur lors de I'utilisation d'un service S. 

Dans une troisitoe etape, en reponse a la requete de bloc RB un 
autre bloc B de la sequence correspondant au service utiUse est ch^e 
a partir du serveur vers la carte. Le chargement d'un bloc B de 
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sequence se fait en une ou plusieurs fois selon les capacites du 
protocole de communication utilise poxir les echanges de donnees entre 
le serve\ir SERV et la carte CARD. Ensuite, on execute les differentes 
commandes CD du bloc envoye comme decrit precedemment. Bien 
5 entendu, cette etape s'applique egalement lors de la premiere etape, si 
le premier bloc a executer de la sequence ne se trouve pas dans la carte. 

De preference, lors d'un premier envoi de commandes, on affiche 
a Tecran de son unite d*abonne SU un message d'attente M^WAIT afm 
de faire patienter Tutilisateur. Avantageusement, des reception dans la 
IP 10 carte d'une commande CD a executer du bloc B de sequence en cours 

He nhargement, on execute ladite commande. Ainsi, on evite d'attendre 

que le bloc B de sequence soit charge entierement avant Texecution 
d'une quelconque commsuide, ce qui pourrait paraitre long audit 
utilisateur. 

15 Dans le cas ou on envoie un bloc B de sequence avec un 

identifiant de requete de bloc RB_ID different de celui de la requete 
envoye, on n'execute pas les commandes de ce bloc et on attend le bon 
bloc B de sequence. 

Dans le cas d'un envoi d'un bloc B de sequence en plusieurs fois, 
^ 20 pendant Texecution d'une commande CD du bloc de sequence, on regoit 

dans la carte au moins une autre commande du bloc B de sequence, 
ladite commande est par suite sauvegardee dans un buffer BUFF de la 
carte CARD en attendant d'etre executee. 

Dans le cas ou, par exemple au bout de trente secondes, aucun 
25 bloc B de sequence n'est envoye en reponse a une requete RB de la 
carte, un message d'erreur M^ERROR est affiche sur Tecran de Timite 
d'abonne SU et on ferme le service S en cours d'utilisation. 

Enfin, lorsque Tensemble des blocs de la sequence a ete appele, 
charge et execute, trois cas se presentent : 
30 - on commence un autre service. 
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- le service n'est pas termine, 

- le service est termine et on ne fait appel a aucun autre service. 
Dans le premier cas. on commence un autre service au moyen 

d'une requate de bloc RB decrite precedemment. L'identifiant du service 
5 en cours S_ID est remplace par I'identifiant du nouveau service 
demande. 

Dans le deuxieme cas, deux choix sont possibles : 
- -soit aucune donnees d'interaction n'est necessaire pour 
continuer le service, par suite on recherche la sequence 
10 suivante. La sequence recherchee est, soit. issue de la 

P^^"^i^^e memoire Ml. soit. 1. s equence r..h...v,.. ... 

envoyee par le serveur SERV si la sequence ne se trouve pas 
dans ladite memoire Ml. Dans ce dernier cas, on envoie une 
requete de bloc RB decrite precedemment. ridentifiant de la 
commande a executer n'etant pas rempli. Des donnees 
d'mteraction sont des donnees provenant d'un serveur de 
service tel qu un serveur bancaire. Par exemple des donnees 
d'mteraction sont un solde de compte bancaire. 
- soit des donnees d'interaction sont necessaires pour continuer 
le service. A cet effet, la carte CARD comporte des moyens de 
requetes de donnees RD, lesdites donnees etant envoyees par 
un serveur de service. Par suite, une requete de donnees RD 
est envoyee a partir de la carte vers le serveur SERV comme le 
montre la figure 8. 

=5 Selon un mode de realisation particuUer. une requ6te de donnees 

comprend les elements suivants : 

- I'identifiant du service S_1D en cours, 

- un nom de requete RD_NAME, 

- ion identifiant de requete RD_ID 
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- des donnees generales RD_DATA correspondant aux 
commandes CD executees precedemment depuis la demiere 
requete quelconque faite au serveur. 
Par exemple, on peut avoir une requete dont le nom est SOLDE, 
5 ce qui correspond a une demande de solde de compte. Le serveior SERV 
du dispositif de chargement interagit avec au moins un serveur de 
service, ici un serveur bancaire SERVBANK et ladite requete est 
transmise par le serveur SERV du dispositif de chargement audit 
serveur bancaire SERVBANK. Par suite, le solde est envoye par le 
^ 10 serveur bancaire SERVBANK au serveur SERV du dispositif de 

r-hargement qui le transmet a la carte CARD pour Tafficher sur I'ecran 

SCR de I'uriite d'abonne SU. 

Ainsi, conformement a la requete RD, un bloc B d'une nouvelle 
sequence comportant les donnees d'interaction demandees est envoye a 
15 partir du serveur vers la carte et, dans le meme temps, on ordonne son 
execution dans la carte CARD. Des reception de la premiere commande 
CD a executer dudit bloc B, celle-ci est executee, soit par le premier 
programme d'execution PI, soit par le deuxieme programme d'execution 
P2, et ainsi de suite.... 
^ 20 Bien entendu, on prevoit des moyens de sauvegarde de bloc B de 

sequence dans la premiere memoire Ml afm de pouvoir Tutiliser dans le 
futur. 

Cependant, il serait egalement interessant de pouvoir utiliser un 
bloc B de sequence, par exemple, meme apres un redemarrage de 

25 Tunite d'abonne SU par Tutilisateur. A cet effet, avantageusement, on 
prevoit que la premiere memoire Ml est non volatile. Ainsi, les blocs de 
sequence, sauvegardes dans la premiere memoire Ml, ne sont plus 
effaces lorsque Tutilisateur a fini d'utiliser un service S ou lorsque 
Tutilisateur eteint son unite d'abonne SU, comme dans le cas d'une 

30 memoire temporaire. Dans le meme temps, cette reutilisation, permet 
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de diminuer le nombre d'interactions entre la carte et le serveur en 
diminuant le nombre de requetes. 

La premiere memoire Ml est representee sur la figure 9. Selon un 
mode de realisation avantageux, elle comporte une premiere et une 
5 deuxieme zones Zl et Z2, la premiere zone Zl etant accessible en 
lecture et ecriture par le serveur et en lecture par la carte, la deuxieme 
zone Z2 etant accessible en lecture et ecriture par la carte. Un partage 
de la premiere memoire en deux zones distinctes presente I'avantage de 
pouvoir envoyer et sauvegarder a tout moment des blocs B de sequence 
10 a la carte au moyen du serveur SERV sans perturber le fonctionnement 

^^"-ice S en cours d'utilisation dans la carte et sans affecf.r 

temps d'execution dudit service. Quant a la carte, elle a acces a la 
premiere zone Zl lors dW recherche. Ainsi, le serveur comporte des 
premiers moyens de sauvegarde de bloc de sequence MSSEQl etant 
15 apte a sauvegarder au moins un bloc de sequence dans la premiere 
zone Zl de la premiere memoire Ml. la carte comporte des deuxiemes 
moyens de sauvegarde de bloc de sequence MSSEQ2 etant apte a 
sauvegarder au moins un bloc de sequence dans la deuxieme zone Z2 
de la premiere memoire Ml. 

20 Selon le meme principe vu pour les blocs de sequence, on peut 

vouloir sauvegarder. par exemple. un numero de compte bancaire afm 
d-evater a TutiUsateur de taper a chaque consultation de compte ledit 
numero. Aussi, on prevoit des moyens de sauvegarde de donnees 
MSDATA permettant de sauvegarder des donnees utiles a un service S 

25 dans la carte. A cet effet. ladite carte CARD comporte une deuxieme 
memoire M2 non volatile comprenant des donnees SDATA propres a au 
moins un service S, 

Ces blocs B de s*quencc sauvegardes dans la premiere zone Zl de 
la premiere memoire MI peuvent etr^ mi« 4 jour grSce aux moj^ns de 
30 mise a jour MU du serveur. De meme, la carte comporte des moyens de 
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mise a jour MUD de donnees SDATA sauvegardees dans la deiaxieme 
memoire M2 de la carte. Par mise a jour, on entend pouvoir modifier, 
effacer ou ajouter dans la carte, un bloc de sequence ou des donnees 
propres a un service. Par exemple, dans le cas d'un service telephonique 

5 permettant a I'utilisateur, d'une part, d'appeler automatiquement un 
repondeur de cinema donnant les seances de films et, d'autre part, 
d'appeler automatiquement un service donnant les cours de la bourse 
en direct, si I'utilisateur n*a pas paye le service boursier, grace auxdits 
moyens de mise a jour, on met a jour dans ladite premiere memoire Ml, 

10 au moins un bloc B de sequence de commandes propre a un service S, 

ici propre au service boiirsier en pffayant Ifiriit service boursier tout cn 

lui laissant les autres services. Ainsi, il est inutile de recharger tout le 
service telephonique et les services sous-jacents. 

Afin d'effectuer les actions d'envoyer un bloc B de sequence a la 

15 carte, d'ordonner Texecution d'un bloc, de sauvegarder ou de mettre a 
jour un bloc ou des donnees SDATA, selon un mode de realisation non 
limitatif, on envoie a partir du serveur SERV vers la carte CARD des 
instructions INS comprenant de preference les elements suivants, 
comme le montre la figure 10 : 

20 - type d'instruction INS^TYPE, 

- longueur des donnees d'entree INSJNLEN, 

- donnees d'entree INSJN. 

Preferentiellement, on a deux types d'instructions : 

- le premier type INS^TYPEl est utilise pour gerer le buffer 
25 BUFF de la carte, par exemple une instruction de premier type 

permet d'envoyer a la carte, un bloc de sequence et/ou 
ordonner a la carte Texecution d'un bloc de sequence. 

- ' le deuxieme type INSjrYPE2 est utilise pour gerer la premiere 

memoire Ml, par exemple une instruction de deuxieme type 



m 
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permet de sauvegarder ou mettre a jour un bloc de sequence 
propre a un service S. 

Comme le montre la figure 11, les donnees d'entree INSJNl de 
premier type INS_TYPE1 sont les suivantes : 
5 - identifiant du service S_ID en cours d'utiHsation, 

- identifiant de sequence SEQ_ID, 

- identifiant de requete RB_ID ou RD_ID, 

- type de Taction ACT_TYPE a effectuer, 

- identifiant de la commande CD.ID a executer en premier, dans 
10 le cas d'un bloc B de sequence envoye, 

: : bloc B de seguenr p a env^yf 

On notera que d'autres donnees d'entree peuvent figurer dans la 
hste donnee ci-dessus, telles que des donnees assurant un transfert 
secunse comme une signature de donnees par exemple. 
15 Les actions pouvant etre effectuees sont les suivantes : 

- execution du bloc de sequence envoye. 

- ne pas executer le bloc de sequence envoye, 

- sauvegarde du bloc de sequence envoye dans une memoii^ 
tampon de la carte sans effacement de ladite memoire 

- sauvegarde du bloc de sequence envoye dans une memoire 
tampon de la carte avec effacement prealable de ladite 
memoire...; 

Les donnees d'entree INS_IN2 de second type INS_TYPE2 sont les 
suivantes : 

25 - identifiant du service S_ID vise, 

- identifiant de sequence SEQJD, 

- type de Taction ACT_TYPE a effectuer, 

- parametres dependants de Taction a effectuer ACT.PAR 

Les actions pouvant avantageusement etre effectuees sont les 

30 suivantes : 
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- effacement d'un bloc de sequence et remplacement par un 
autre, 

- ajout d'lin autre bloc de sequence propre a un service, 

- remplacement d'un ensemble de commandes dans un bloc de 
5 sequence... 

Bien entendu, dans les deux cas, la liste des actions pouvant etre 
effectuees n'est pas limitative. 

A la reception d'une instruction INS dans la carte, ladite 
instruction est interpretee dans la carte et les actions associees 
10 executees. 

On notera que, dans le domaine de la telephonie mobile, 

preferentiellement, afin de raster compatible avec les unites d'abonne 
SU et cartes CARD existants sur le marche, une instruction ou une 
requete est envoyee, par voies hertziennes, au moyen d'un protocole de 

15 communication base sur un service de messages courts standardise 
couramment appele SMS. Pour les autres domadnes, on utilise le meme 
protocole ou tout autre protocole connu de Tetat de la technique. 

Cependant, on ne peut pas toujours envoyer la totalite d'une 
instruction ou requete au moyen d*un message court en raison des 

20 capacites limitees desdits messages courts. C'est pourquoi, comme le 
montre la figure 12 frequemment, on envoie urie instruction INS au 
moyen de plusieurs messages courts SMS. Ainsi, une instruction INS 
est decoupee et envoyee par sections SJNS. U en va de meme pour une 
requete. Un message court comprend un emplacement utilisateur 

25 USERDATA dans lequel on place une section SJNS d'instruction. Afin 
d\atiliser au maximum ledit emplacement utilisateur, on ne laisse 
aucun espace de libre. Aussi, un bloc de sequence B compris dans une 
instruction INS comprend tout ou partie d'une commande selon le 
decoupage en sections de ladite instruction INS. 



16 

De la meme maniere, des commandes, telles que les commandes 
executees par te deuxieme programme P2 de IWite d'abonne SU 
comme par exemple ur>e commande d'afflchage de texte a recraii'vue 
precedemment, sent compatibles avec les commandes dafmies dans le 

s «andardGSM11.14.appetees6ga]ememcommandesSIMTOOLKIT 
arm d'etre comprehensibles par les unites d'abonn* standards Ausli 
on prtvoit que la carte comporte des moyens de transcdption MT dW 
commande vers une commande SIMTOOLMT. 

La presente invention s'appUque particulierement 4 des services 
10 de type internet. Comme le montn= la figu-e 13, un serveur de service 
. interne. SERVWEB comporte de. ^ ^ ces internet ^p .^.^.., 

pages web WEBPAGE codaes dans un langage com>u tels que les 
langages HTML ou WML. Par un .^seau de communication standard 
NET. un serveur SERV du dispositif de chargement de commandes 
5 selon rinvention, communique avec le serveur internet. Dans le serveur 
de chargement, on accede au service internet au moyen des pages WEB 
transmises par le reseau de communication. Le serveur SERV du 
disposiUf de invention, comporte des moyens de transcription MTWEB 
dune page web en sequences SEQ de commandes d&rites 
0 precedemment. Alin de permettre ■•acc^s aux services internet a un 
ut.lisa.eur donna, il suffit de charger, au fur et a mesure des besoins de 
rutUisateur, les blocs B des sequences ainsi transcrits dans la carte 
CARD de I'utilisateur comme vu precedemment. Lutilisateur a ainsi 
acces au service internet INTERNET au moyen de Tea^n SCR de son 
umte d abonne. Bien entendu, pour r^pondre A une ..quate de la carte 
.1 est necessaire d'acceder au serveur internet. A cet effet, le serveu.^ 
SERV du dispositif de rinvention comporte des tnoyens d'inten.gation 
MA du serveur internet pour obtenir les donnees nacessaires a ladite 
requete. 
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Bien entendu, le cadre de I'invention n'est nullement limite au 
mode de realisation decrit et s'etend a d'autres modes de readisation 
dans lesquels, notamment, le dispositif de chargement est poiirvu de 
moyens complementaires destines a assiirer une complete securite des 
donnees echangees. 
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REVENDICATTmffig 

1 - Dispositif de chargement de commandes a partir d'au moins 
un serveur (SERV) vers au moins une carte a circuit integre 
(CARD) connectee a une unite d'abonne (SU), ladite carte 
comprenant un premier programme d'execution (Pi) de 
commandes et une premiere memoire (Ml), caracterise en ce que, 
d'une part, ledit serveur (SERV) comprend : 

- des moyens de chargement (ML) dans la carte d'au moins un 
bloc (B) d-une sequence (SEQ) de commandes, propre a un 

^^'^^^^ (S)> au moins une com mande (CD) dudit bloc (B) e.t.r.t 

executee par le premier programme d'execution (PI) ou 
transmise a I'unite d'abonne (SU) et executee par un deuxieme 
programme d'execution (P2), 

- des moyens de sauvegarde (MS) d'au moins un bloc (B) de 
sequence dans la premiere memoire (Ml), 

- des moyens de mise a jour (MU) etant aptes a modifier, effacer, 
ajouter, dans la premiere memoire (Ml) au moins un bloc (B)' 
de sequence, 

et, d'autre part, la carte (CARD) comprend : 

- des moyens de recherche de bloc (B) de sequence etant aptes a 
rechercher un bloc de sequence propre a un service, apres 
I'execution d 'une commande (CD) d'un bloc (B). 

2 - Dispositif selon la revendication 1, caracterise en ce que la 
premiere memoire (Ml) est non volatile. 

3 - Dispositif selon les revendications 1 ou 2. caracterise en ce 
que ladite carte comporte une deuxieme memoire (M2) non 
volatile comprenant des donnees propres a au moins un service 
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4 - Dispositif selon l\ane quelconque des revendications 
precedentes, caracterise en ce que le bloc (B) de sequence 
recherche est envoye par le serveur (SERV). 

5 - Dispositif selon l*une quelconque des revendications 
5 precedentes, caracterise en ce que le bloc (B) de sequence 

recherche est issu de la premiere memoire (Ml). 

6 - Dispositif selon l\ine quelconque des revendications 
precedentes, caracterise en ce que la premiere memoire (Ml) 
comporte une premiere et une deiaxieme zones, la premiere zone 

10 (Zl) etant accessible en lecture et ecriture par le serveur et en 

Iprtiire par la carte, la deuxieme zone (Z2) etant accessible en 

lecture et ecriture par la carte. 

7 - Dispositif selon l\ine quelconque des revendications 
precedentes, caracterise en ce que la carte (CARD) comporte des 

15 moyens de requetes de donnees (RD), lesdites donnees etant 

envoyees par un serveur de service. 

8 - Dispositif selon Tune quelconque des revendications 
precedentes, caracterise en ce que la carte comporte des moyens 
d'interpretation (MI) de blocs de sequence de commandes. 

20 9 - Procede de chargement de commandes a partir d'au moins un 

serveur (SERV) vers au moins une carte a circuit integre (CARD) 
connectee a une unite d'abonne (SU), ladite carte comprenant un 
premier programme d*execution (PI) de commandes et une 
premiere memoire (Ml), caracterise en ce qu'il comporte les 

25 etapes selon lesquelles : 

- on charge, a partir du serveur vers la carte, au moins un bloc 
(B) de sequence (SEQ) de commandes, propre a un service (S), 

- on execute au moins une commande (CD) dudit bloc (B) au 
moyen du premier programme d'execution (PI) ou on la 
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transmet a I'unite d'abonne (SU) et on I'execute au moyen d'un 
deuxieme programme d'execution (P2). 

- on sauvegarde au moins un bloc (B) de sequence dans la 
premiere memoire (Ml). 

10 - Precede selon la revendication 9, caracterise en ce qu'il 
comporte une etape supplementaire selon laquelle : 

- on recherche un autre bloc (B) de sequence, propre a un 
service, apres I'execution d'une commande (CD) d'un bloc (B) 
de sequence. 

11 - Precede selon la revendication 10, caracterise en ce que le 
bloc (B) de sequence recherche est envoye par le serveur (SERV) 



12 - Precede selon la revendication 10, caracterise en ce que le 
bloc (B) de sequence recherche est issu de la premiere memoire 
(Ml). 

13 - Precede selon IW quelconque des revendications 9 ou 12 
caracterise en ce qu il comporte une etape supplementaire selon 

laquelle : 

- on met a jour dans ladite premiere memoire (Ml), au moins un 
bloc (B) de sequence de commandes propre a un service (S). 

14 - Precede selon I'une quelconque des revendications 9 a 13 
caracterise en ce que la premiere memoire (Ml) est non volatile. 

15 - Precede selon IW quelconque des revendications 9 a 14 
caracterise en ce que ladite carte (CARD) comporte une deuxieme 
memoire (M2) non volatile comprenant des donnees propres a au 
moins un service. 

16 - Precede selon I'une quelconque des revendications 9 a 15 
caracterise en ce que la premiere memoire (Ml) comporte une' 
premiere et une deuxieme zones, la premiere zone (Zl) etant 
accessible en lecture et ecriture par le serveur et en lecture par la 
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carte, la deuxieme zone (Z2) etant accessible en lecture et ecriture 
par la carte. 

17 - Procede selon Tune quelconque des revendications 9 a 16, 
caracterise en ce qu'il comporte une etape supplementaire selon 

5 laquelle : 

- une requete de donnees (RD) est envoyee a partir de la carte 
vers un serveur de service. 

18 - Procede selon l\ine quelconque des revendications 9 a 17, 
caracterise en ce qu'il comporte une etape supplementaire selon 

10 laquelle : 

- on interprete dans la cairte au moins un bloc (B) de sequence 

de commandes. 

19 - Procede selon Tune quelconque des revendications 9 a 18, 
caracterise en ce qu'il comporte une etape supplementaire selon 

15 laquelle : 

. des reception dans la carte d'une commande (CD) a executer 
d*un bloc (B) de sequence en cours de chargement, on execute 
ladite commande. 

20 - Procede selon Tune quelconque des revendications 9 a 19, 
20 caracterise en ce qu'il comporte une etape supplementaire selon 

laquelle : 

- pendant Texecution d'une commauide (CD) d\in bloc (B) de 
sequence, on regoit dans la carte au moins une autre 
commande (CD) du bloc de sequence. 
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